[レポート]脱シャーディング！！NewSQLのTiDBで実現 ~楽しいね！を世界中の日常へお届けするためにエンジニアリングで行ったこと #CEDEC2023 #classmethod_game

sora

2023.08.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、ゲームソリューション部のsoraです。
今回は、CEDEC2023のセッションレポートを書いていきます。

セッション概要

脱シャーディング！！NewSQLのTiDBで実現 ~楽しいね！を世界中の日常へお届けするためにエンジニアリングで行ったこと

受講スキル：
・ゲーム開発に関わる方
・データベースでお悩みを抱えている方

得られる知見：
・分散型データベースの基本的な概念とTiDBの特徴理解
・ゲーム基盤でのTiDB活用ポイント
・DB選定時のワンポイント

セッションの内容：

楽しいね！と言ってもらえるゲームを作る、ゲーム業界に携わるみなさんにとっても最も重要なことだと思いますが、一方でユーザー様に長く楽しんで頂くために足元を整えることもかかせません。
運用フェーズを見据え、想定を超えるアクセスがあった際どのようにして機会損失が発生しないようにするか、運用コストの削減にエンジニアリングの観点でどう寄与していくか、特にデータベースのシャーディングや先の読めないサイジングをどう解決していくかはひとつの大きなテーマかと思います。
シャーディングなしで高負荷にも耐えられるスケール性を持ちつつ、リソース活用の最適化が容易なものがあったらイイと思いませんか？
慣れ親しんだMySQL互換でこれらの課題を解決してくれるNewSQLデータベースのTiDBを検証し、実際に採用したポイントやその効果について話します。

レポート（TiDBについて）

はじめに

アジェンダとPingCAP社についての説明です。
TiDBはMySQL互換のNewSQLです。

RDBMSとNewSQLの違い

・ストレージエンジン
RDBMSではB+Tree、もしくはその亜種が使用されています。
B+Treeは、上書き型であり読み取りに強いです。
NewSQLで使用されているLSM(Log-Structured Merge)-Treeは、追記型でメモリにどんどんデータを追加していく方式で書き込みに強いです。
ソートとマージをしつつ、強い圧縮をかけながらディスクに保存していく方式になっています。

・拡張性
NewSQLは、データを分割管理し、ReadのスケールだけでなくWriteのスケールも可能にします。
各データのリーダーに対して、I/Oを行う構成になっています。

ストレージエンジンについて、B+Treeはディスク上のページに次のページへのインデックスを挟むことで、検索性能が高いです。
LSM-Treeは、レコードの追加とコンパクション（ソート+マージ）が分離されていて、書き込み性能が高いです。
拡張性について、ゲーム業界特有の要素として書き込み処理が多い特徴があるので、Writeのスケールができることは大きなメリットだと思います。

ストレージエンジンの詳細な部分は、以下のブログがわかりやすかったです。

TiDBのアーキテクチャー

TiDBは3つ+オプション1つの4つの要素で構成されています。
・TiDB：コンピューティングの役割を担う。アプリからSQLクエリを受けて解釈してストレージであるTiKVに対してI/Oを行う。
・PD：司令塔の役割を担う。TiKVで持つデータの配置情報を管理したりするが、ユーザー側であまり意識しなくてよい要素である。
・TiKV：行指向ストレージであり、ACIDトランザクションを提供する分散KVS（Key-Value Store）である。メインのストレージがここ。
・TiFlash（オプション）：列指向ストレージであり、TiKVからレプリケーションをかけることでHTAPを実現できる。

TiDBは、水平垂直方向にスケールが可能です。
4つの要素に分解されているものの、アプリケーション側から見ると単一のDBとして扱うことができます。
TiDB CloudのGUI上やAPIで簡単にスケールが可能です。

TiDBのデータ管理の仕組み

Regionという単位でデータを分割し、Leader（読み書き対象）1つとFollower（バックアップ）2つに分けて3面コピーでTiKVに保管されます。
TiFlashがある場合はLeaner（カラムナ）という要素を含めて1つのRaft Groupを形成します。
データの分割は、PDでコントロールして自動で行います。（Autoシャーディング）

ダウンタイムに対する動き

TiKVに障害が発生した場合は、障害が起きたTiKVのLeaderの役割がFollowerに移ります。
ダウンタイムはなく、FollowerがLeaderに昇格するまでの時間（数秒程度）のクエリ遅延が発生します。
TiKVのアップデートについても、Leaderをずらしつつアップデートするためダウンタイムは発生しません。

TiDBのラインナップ

TiDB CloudはServerlessとDedecated、OSS版としてSelf-Hostedの3パターンがあります。
Serverlessは従量課金であり、開発環境に採用しやすく、本番環境への導入などで高負荷を求める場合はDedecatedを使用することが多いとのことです。

Serverlessであれば無料で使える枠（5GiB ストレージ、毎月50Mリクエストユニット）があるので、無料で気軽に触ってみることもできます。

分析周りでのメリット

DB負荷について、従来のDBであれば取得すべきデータが本番にない場合に、分析クエリの処理により負荷がかかってしまいます。
TiDBでは、クエリに対してリソースをコントロールすることができるため、分析はリソースの何パーセントまでしか使用できないようにするといったことができます。
SQLが使えない問題に対しては、自然言語処理を用いたChat2Query機能を持っているため、SQLの知識がなくてもどのような処理がしたいかを記載するだけでSQL文を自動生成できます。

レポート（TiDBの活用について:ワンダープラネット）

はじめに

アジェンダとワンダープラネット社が開発したタイトルについての紹介です。

データベースへの課題感と対策

データが増えてくるとパフォーマンスが劣化してしまうことが課題としてありました。
元々はAuroraを使用している中で出た課題に対して様々な対策をしてきたものの、Writeのスケールができないこと・NoSQLでは使いづらさやトランザクションの問題があること・シャーディングは結構な稼働がかかることが問題としてありました。

ゲーム特有の要素として、Writeの処理が多いことや保持するデータ量が多いことがあり、これに対してWriteのスケールができることや自動シャーディングの部分はTiDBで解決できる大きなメリットだと思います。
シャードの増減には、数か月の検討を重ねて行うこともあり、運用稼働としても大きな部分だと思います。

TiDB Cloudの検証

元々使用していたAuroraとTiDBを比較検証しました。
最近ではゲーム会社での事例も多かったが、本当に問題ないのかを確認したとのことです。
処理性能に関しては、Auroraと比較して単体のクエリ処理速度が遅いことの影響が許容できるかどうかがポイントになりそうだと感じました。レスポンスは遅くなったがエラー率は0パーセントでした。
スロットリングは発生せず、クエリの遅延だけで済みました。
エラーではなく遅延してでも処理してくれる方が良かったため、これは良い挙動だったとのことです。拡張性について、Writeのスケールアウトができる部分が大きなメリットとしてあります。
スケールインやスケールアップ/ダウン時にコネクション再接続が必要になることは注意点としてあります。
コストとしては、最小コストが大きかったり、Auroraとはあまり変わらないため、費用の削減として導入するものではないとのことでした。

コストに関しては、自動シャーディングの部分や可用性が高いことを考えると、運用稼働が減らせるメリットが多く、人件費まで視野を広げるとコスト削減になる可能性は高いと思いました。 TiDBはMySQL完全互換ではないことには注意が必要とのことです。
また、アラートに関して、Auroraであればそれぞれのメトリクスに対して設定が可能だけれど、TiDBだと簡易なアラート機能しかなく細かく設定しようとするとNewRelicやDataDogといった外部ツールを経由させる必要があります。また、MySQLの全ての機能をサポートしているわけではない点には注意が必要です。
ただし、シンプルなクエリであればそのまま移行しても問題がなく、移植性の高さも感じました。
TiDB Cloudを開発中のタイトルへ導入していて、細かい課題はありつつもおおむね問題なく動作しているとのことでした。